Avoid using the unstable let_chains syntax (&& let Err(e) = ...) which will cause a compilation error on stable Rust. Instead, use a standard nested if let block. Additionally, use the in-memory provider_status store from AppState to prevent race conditions.

Add provider_status to AppState to keep the connection test statuses in memory. This allows safe, synchronized access and avoids concurrent file read/write race conditions.

Read the connection test status directly from the in-memory provider_status store in AppState instead of loading it from disk on every request. This is much faster and safer.

Use tauri::State<'_, AppState> to access the in-memory provider_status store and eliminate the race condition on concurrent connection tests.

#[tauri::command]
async fn test_asr_connection(
    state: tauri::State<'_, AppState>,
    request: ConnectionTestRequest,
) -> ConnectionTestResult {
    let connection_id = request
        .connection_id
        .clone()
        .map(|id| id.trim().to_string())
        .filter(|id| !id.is_empty())
        .unwrap_or_else(|| "default".into());
    let provider = request.provider.trim().to_string();
    let result = match provider.as_str() {
        "mock" => Ok("Mock ASR is available.".to_string()),
        "openai-compatible" | "" => test_openai_compatible_asr(request).await,
        other => Err(anyhow::anyhow!("unsupported ASR provider: {}", other)),
    };
    let mut result = connection_test_result(provider, result);
    if result.ok && result.provider == "mock" {
        result.message_key = Some("settings.mock_asr_ok".into());
    }
    result.tested_at = Some(chrono::Utc::now().to_rfc3339());
    save_connection_test_status(&state, "asr", &connection_id, &result);
    result
}

Use tauri::State<'_, AppState> to access the in-memory provider_status store and eliminate the race condition on concurrent connection tests.

#[tauri::command]
async fn test_llm_connection(
    state: tauri::State<'_, AppState>,
    request: ConnectionTestRequest,
) -> ConnectionTestResult {
    let connection_id = request
        .connection_id
        .clone()
        .map(|id| id.trim().to_string())
        .filter(|id| !id.is_empty())
        .unwrap_or_else(|| "default".into());
    let provider = request.provider.trim().to_string();
    let result = match provider.as_str() {
        "mock" | "" => Ok("Mock LLM is available.".to_string()),
        "openai-compatible" => test_openai_compatible_llm(request).await,
        other => Err(anyhow::anyhow!("unsupported LLM provider: {}", other)),
    };
    let mut result = connection_test_result(provider, result);
    if result.ok && result.provider == "mock" {
        result.message_key = Some("settings.mock_llm_ok".into());
    }
    result.tested_at = Some(chrono::Utc::now().to_rfc3339());
    save_connection_test_status(&state, "llm", &connection_id, &result);
    result
}

Update save_connection_test_status to lock and write to the in-memory provider_status store in AppState instead of performing unsafe concurrent file reads and writes.

Load the provider status from disk during application startup so it can be kept in memory.

            let status_path = provider_status_path(app.handle());
            let provider_status = load_provider_status(&status_path);

Initialize the provider_status mutex in AppState during setup.

Await saveConfig() before running the connection test. This ensures that the draft settings are persisted to disk and any stale status is correctly reset before the test runs, preventing UI state mismatches.

Await saveConfig() before running the connection test. This ensures that the draft settings are persisted to disk and any stale status is correctly reset before the test runs, preventing UI state mismatches.

If timestamp is an invalid date string, Date.parse(timestamp) returns NaN. Since Number.isFinite(NaN) is false, the condition !Number.isFinite(elapsedMs) evaluates to true, causing the function to incorrectly return "Last tested just now" instead of handling the parsing failure. Adding a check for Number.isNaN(time) prevents this bug.

The use of && let (let-chains) is an unstable Rust feature (RFC 2497) and requires #![feature(let_chains)] to compile. To ensure compatibility with stable Rust and improve readability, this should be refactored into nested if statements.

Performing synchronous file I/O (save_provider_status) directly inside an async context (called by the async commands test_asr_connection and test_llm_connection) can block the Tokio executor threads. Offloading this blocking operation to tokio::task::spawn_blocking is highly recommended to maintain responsiveness.

Using String::truncate with a hardcoded byte limit can cause a panic if the truncation index falls in the middle of a multi-byte UTF-8 character (e.g., Chinese characters or emojis in error messages). It is safer to find the nearest valid character boundary before truncating.

    if message.len() > 500 {
        let mut limit = 500;
        while !message.is_char_boundary(limit) {
            limit -= 1;
        }
        message.truncate(limit);
        message.push('…');
    }

The let_chains feature (&& let Err(e) = ...) is currently unstable in Rust. To ensure compatibility with stable Rust compilers, it is recommended to use nested if let statements instead.

The save_provider_status function performs synchronous file I/O (std::fs::write). Calling this directly on the async executor thread in save_connection_test_status blocks the thread, which can degrade application responsiveness. Since ProviderStatusStore implements Clone, we can clone the store, drop the lock guard early, and perform the file write inside tokio::task::spawn_blocking to keep the async executor thread free.

        let path = state.provider_status_path.clone();
        let store_clone = store.clone();
        drop(store);
        tokio::task::spawn_blocking(move || {
            if let Err(e) = save_provider_status(&path, &store_clone) {
                tracing::warn!(
                    "failed to save provider status to {}: {}",
                    path.display(),
                    e
                );
            }
        });

The connection test for the OpenAI-compatible ASR provider does not have a timeout. If the configured endpoint is unresponsive or hangs, the test will block indefinitely, keeping the UI in a 'testing' state. Wrapping the async call in tokio::time::timeout ensures the test fails gracefully after a reasonable duration (e.g., 30 seconds).

The connection test for the OpenAI-compatible LLM provider does not have a timeout. If the configured endpoint is unresponsive or hangs, the test will block indefinitely, keeping the UI in a 'testing' state. Wrapping the async call in tokio::time::timeout ensures the test fails gracefully after a reasonable duration (e.g., 30 seconds).